The present invention is directed to multi-programming systems on objected oriented platforms. More particularly, the invention is directed to threading control.
As set forth in U.S. Pat. No. 5,499,365, fully incorporated herein by reference, object oriented programming systems anld processes, also referred to as "object oriented computing environments," have been the subject of much investigation and interest. As is well known to those having skill in the art, object oriented programming systems are composed of a large number of "objects." An object is a data structure, also referred to as a "frame," and a set of operations or functions, also referred to as "methods," that can access that data structure. The frame may have "slots," each of which contains an "attribute" of the data in the slot. The attribute may be a primitive (such as an integer or string) or an object reference which is a pointer to another object. Objects having identical data structures and common behavior can be grouped together into, and collectively identified as a "class."
Each defined class of objects will usually be manifested in a number of "instances". Each instance contains the particular data structure for a particular example of the object. In an object oriented computing environment, the data is processed by requesting an object to perform one of its methods by sending the object a "message". The receiving object responds to the message by choosing the method that implements the message name, executing this method on the named instance, and returning control to the calling high level routine along with the results of the method. The relationships between classes, objects and instances traditionally have been established during "build time" or generation of the object oriented computing environment, i.e., prior to "run time" or execution of the object oriented computing environment.
In addition to the relationships between classes, objects and instances identified above, inheritance relationships also exist between two or more classes such that a first class may be considered a "parent" of a second class and the second class may be considered a "child" of the first class. In other words, the first class is an ancestor of the second class and the second class is a descendant of the first class, such that the second class (i.e., the descendant) is said to inherit from the first class (i.e., the ancestor). The data structure of the child class includes all or the attributes of the parent class.
Object oriented systems have heretofore recognized "versions" of objects. A version of an object is the same data as the object at a different point in time. For example, an object which relates to a "work in progress", is a separate version of the same object data which relates to a completed and approved work. Many applications also require historical records of data as it existed at various points in time. Thus, different versions of an object are required.
Two articles providing further general background are E. W. Dijkstra, The Structure of "THE " Multi programming System, Communications of the ACM, Vol. 11, No. 5, May 1968, pp. 341-346, and C.A.R. Hoare, Monitors: Operating Systems Structuring Concepts, Communications of the ACM, Vol. 17, No. 10, October, 1974, pp. 549-557, both of which are incorporated herein by reference. The earlier article describes methods for synchronizing using primitives and explains the use of semaphores while the latter article develops Brinch-Hansen's concept of a monitor as a method of structuring an operating system. In particular, the Hoare article introduces a form of synchronization for processes and describes a possible method of implementation in terms of semaphores and gives a proof rule as well as illustrative examples.
The following terms are or may be used herein:
Thread--a parallel execution unit within a process. A monitor synchronizes, by forced sequentialization, the parallel access of several simultaneously running threads, which all call up functions of one object that are protected through a monitor. PA1 Synchronizations-Primitive--a means of the operating system for reciprocal justification of parallel activities. PA1 Semaphore--a Synchronizations-Primitive for parallel activities. PA1 Mutex--a special Synchronizations-Primitive for parallel activities, for mutual exclusion purposes, it includes a critical code range. PA1 Condition Queue--an event waiting queue for parallel activities referring to a certain condition. PA1 Gate Lock--a mutex of the monitor for each entry-function, for protection of an object by allowing only one parallel activity at a time to use an Entry-Routine of the object. PA1 Long Term Scheduling--longtime delay of one parallel activity within a condition queue or event waiting queue for parallel activities. PA1 Broker--a distributor. PA1 (a) at least one dynamic slot providing asynchronous execution of programmer submitted functions; PA1 (b) at least one synchronous timer slot; PA1 (c) at least one asynchronous timer slot; PA1 (d) at least one exception slot for handling programmer defined system exception callbacks; PA1 (e) at least one slot providing external event notification for programmer events; PA1 (f) a thread dispatcher; PA1 (g) a main dispatcher; PA1 (h) a signaling dispatcher; PA1 (I) a thread manager for managing execution of threads; PA1 (j) message block memory for storage of message blocks; PA1 (k) a list of SynchHandles that return an error external event notification for user events; PA1 (l) an administrator for mapping of SynchHandles to slot identifiers; and PA1 (m) a queue for blocked threads. PA1 an initial state when nonsignalled and not yet used; PA1 a queued state when nonsignalled and in use; PA1 a started state when nonsignalled and in use and a submitted function is being executed; PA1 a finished state when signalled and in use and execution of a submitted function is complete; PA1 a callback active (CbActive) state when signalled and in use and a submitted function is being executed; and PA1 an idle state when signalled and no longer in use. PA1 means for centrally dispatching threads and providing runtime configurable delivery of event handlers; PA1 means for interrupting execution of event handlers; PA1 means for blocking waits for events in event handlers; PA1 means for executing functions asynchronously with respect to events occurring external to the interface system; and PA1 means for executing asynchronous timer handlers in parallel to other running event handlers. PA1 means for interrupting callback driven systems, including interrupting callbacks themselves; PA1 an asynchronous dispatcher; PA1 a synchronous dispatcher; PA1 an asynchronous signaling dispatcher; PA1 a thread manager; and PA1 a plurality of different types of slots used for administrating activities assigned to them. PA1 at least one dynamic slot which administrates asynchrony for an application programmer; PA1 at least one synchronous timer slots which administrates synchronous timers; PA1 at least one asynchronous timer slot which administrates asynchronous timers; PA1 at least one exception slot which administrates user defined system exception callbacks; and PA1 at least one generic slot which administrates waitFor . . . () functionality for user events.
The following acronyms also are or may be used herein:
______________________________________ AFM Asynchronous Function Manager SESAM Service & Event Synchronous Asynchronous Manager
Programmable Area Logic API Application Programmers Interface IDL Interface Definition Language ATOMIC Asynchron Transport Optimizing observer-pattern-like system supporting several Modes (client/server - push/pull) for an IDL-less Communication subsystem (This is the subject of commonly assigned application Serial No. 081676,859, At- torney Docket No. P960462 incorporated herein by reference) XDR External Data Representation I/O Input/Output IPC Inter Process Communication CSA Common Software Architecture (a Siemens AG computing system convention) SW Software ______________________________________